Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/src/components/mypage/ActivitySection.jsx`:
- Around line 11-27: fetchActivityLogs currently leaves the UI ambiguous during
network delays because it only updates items and totalPages; add explicit
loading and error state handling: introduce local state variables (e.g.,
loading, setLoading and error, setError) in ActivitySection.jsx,
setLoading(true) before awaiting getActivityLogs(page, size), clear error on
start, set items and totalPages on success, setError(error) in the catch block,
and setLoading(false) in a finally block; also update the component render
(including the JSX referenced around the fetch usage lines ~51-65) to show a
loading indicator when loading is true, an error message when error is set, and
only show the "no items" / list UI when not loading and no error.

In `@frontend/src/components/mypage/ChangeInfoForm.jsx`:
- Around line 22-29: The effect in ChangeInfoForm (useEffect) currently only
calls onValidChange when isValid is true, so the parent never sees validation
become false; change the effect to call onValidChange on every validation change
(dependencies: currentPassword, newPassword, confirmPassword) and pass the
validation state and data — e.g., call onValidChange(isValid ? {
currentPassword, newPassword } : null) or pass an object like { valid: isValid,
data: isValid ? { currentPassword, newPassword } : null } so the parent
(EditProfileModal) can clear formValid and passwordData when invalid.

In `@frontend/src/components/mypage/EditProfileModal.jsx`:
- Around line 90-118: Add an isSubmitting state flag and use it to prevent
duplicate requests: at the top of handleSubmit check if isSubmitting and return
early, set isSubmitting = true before any await/updateUserDetails call, and
ensure you set isSubmitting = false in a finally block so it always resets; also
disable the primary button (e.g., disabled={isSubmitting} or show a loading
state) so the UI cannot trigger parallel submits during the mode/step flows
(references: handleSubmit, updateUserDetails, mode, step); apply the same
isSubmitting guard and UI disable to the other submit handler(s) in this
component that perform PATCH requests (the second submit path handling
email/password flows).
- Around line 124-129: The modal lacks ARIA dialog semantics; update the modal
container (the element with className styles.modal) to include role="dialog" and
aria-modal="true", add an id to the header element that renders getHeaderTitle()
(e.g., "edit-profile-modal-title") and connect it via aria-labelledby on the
dialog, and ensure the header <h1> uses that id so screen readers recognize the
title; make these changes inside the EditProfileModal component (look for
styles.overlay, styles.modal, and the getHeaderTitle() usage).

In `@frontend/src/components/mypage/EditProfileModal.module.css`:
- Around line 1-27: The overlay and modal lack vertical scroll control causing
the modal bottom to be inaccessible on small viewports; update the .overlay to
allow scrolling (e.g., overflow-y: auto; -webkit-overflow-scrolling: touch) and
set .modal to a max-height based on the viewport (e.g., max-height: calc(100vh -
40px)) with overflow-y: auto so its internal content can scroll while keeping
the modal centered and paddings intact; apply these changes to the .overlay and
.modal rules to ensure the bottom buttons remain reachable on
mobile/virtual-keyboard scenarios.

In `@frontend/src/components/mypage/EmailVerify.jsx`:
- Around line 19-20: The AbortController created in the EmailVerify component
isn't wired to the actual request: set abortRef.current to the new controller
(and call abortRef.current.abort() if an existing controller exists) before
making the network call, and pass controller.signal into the fetch/axios request
so the previous request can be cancelled; update the code around the controller
creation (where controller is instantiated) and the request invocation (where
signal should be supplied) to use abortRef and controller.signal accordingly.
- Around line 46-58: The current "currentEmail" verification allows any email
because handleSend calls sendVerificationNumber({ email }) with only the
user-supplied value; change the flow so the checked email is the authenticated
user's email (not an arbitrary input) or enforce server-side matching: update
the client-side handlers (handleSend and the corresponding verify handler around
lines where sendVerificationNumber and verifyVerificationNumber are called) to
fetch/use the logged-in user's email from the auth state (or disable editing of
the currentEmail input) before calling sendVerificationNumber, and/or update the
API endpoints invoked by sendVerificationNumber/verifyVerificationNumber to
validate that the target email equals the authenticated user's email
(session/token) so an attacker cannot verify a different address; reference
handleSend, sendVerificationNumber, verifyVerificationNumber, and the
EditProfileModal currentEmail step when making the change.

In `@frontend/src/components/mypage/PointsSection.jsx`:
- Line 1: The page fetch logic in PointsSection is vulnerable to out-of-order
responses when users click page buttons rapidly; update the component
(PointsSection) so the effect/handler that calls the data loader (e.g.,
fetchItems or fetchPoints) cancels stale requests or ignores late responses:
either use an AbortController and pass its signal to the fetch call inside
useEffect and abort the previous controller on cleanup, or implement a monotonic
requestId/sequence token checked before calling setItems/setLoading; ensure this
change touches the useEffect that depends on currentPage (and any page change
handler) so only the latest response updates state (items, loading, error) and
previous responses are ignored/aborted.

In `@frontend/src/components/mypage/ProfileCard.jsx`:
- Around line 9-15: The roleMap constant is missing an entry for PENDING_MEMBER
so pending users fall back to the generic label; update the roleMap object
(symbol: roleMap in ProfileCard.jsx) to include a PENDING_MEMBER key with the
appropriate Korean label (e.g., '승인대기' or similar) and ensure any other nearby
mappings (lines around the existing ROLE keys) are consistent with backend
Role.java so pending members display correctly.
- Around line 26-27: The debug console log in ProfileCard.jsx prints the full
/api/user/details response (api.get('/api/user/details')) which exposes PII
(email, phoneNumber); remove the console.log('사용자 정보:', response.data) from the
release code or replace it with a safe log that only outputs non-PII fields
(e.g., username/id) by destructuring response.data to exclude email and
phoneNumber before logging or simply delete the log line in the function that
handles the API response.

In `@frontend/src/utils/axios.js`:
- Around line 2-5: The axios instance is created with baseURL set to an empty
string while BASE_URL is computed, causing API requests and the token refresh
flow (which already uses BASE_URL) to target different hosts in production;
update the axios.create call (the exported api instance) to use baseURL:
BASE_URL so normal API calls and the token-reissue/refresh requests use the same
origin/host, and keep withCredentials: true to preserve credentials across both
flows.

In `@frontend/src/utils/myPageMenu.js`:
- Around line 19-28: getActivityLogs currently returns a raw array but
ActivitySection.jsx expects an object with content and totalPages; update
getActivityLogs to normalize the API response: if response.data is an object
with response.data.content return that as-is, otherwise wrap the array into {
content: response.data, totalPages: 1 } (or compute totalPages from a response
header if backend provides total count) so callers (ActivitySection.jsx) always
receive { content, totalPages } from getActivityLogs.

---

Nitpick comments:
In `@frontend/src/components/attendancemanage/SessionManagementCard.jsx`:
- Around line 4-7: Remove unused imports and props: delete the unused useContext
import and the addRound import from SessionManagementCard.jsx and remove the
unused handleAddRounds prop usage from this component (handleAddRounds is only
used inside RoundDayPicker). Update any destructuring from useAttendance to stop
expecting handleAddRounds so the context hook usage matches actual consumers
(e.g., adjust the useAttendance() destructure in SessionManagementCard to
exclude handleAddRounds). Ensure RoundDayPicker continues to receive and use
handleAddRounds from useAttendance where needed.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/src/components/mypage/ActivitySection.jsx`:
- Around line 11-31: The fetchActivityLogs calls can race and allow earlier
(slower) responses to overwrite state; update fetchActivityLogs/useEffect to
ensure only the latest request updates state by adding a cancellation or
sequence guard: either create and use an AbortController for each call and abort
the previous controller before starting a new fetch (wiring the
controller.signal into getActivityLogs), or maintain a monotonic requestId
(useRef) that you increment before each call and check when responses arrive,
only calling setItems/setTotalPages if the response's requestId matches the
latest; update getActivityLogs invocation and the useEffect that triggers
fetchActivityLogs(page) to use this mechanism so stale responses can’t update
the component state.

In `@frontend/src/components/mypage/EditProfileModal.jsx`:
- Around line 37-42: The decorative right-arrow images inside the
EditProfileModal.jsx menu buttons are currently using alt=">" which creates
unnecessary screen-reader noise; update both <img> instances (the ones inside
the buttons that call handleMenuSelect and use styles.menuItem) to be treated as
purely decorative by setting alt="" and adding aria-hidden="true" on the <img>
elements so screen readers ignore them while preserving visual UI.
- Around line 56-61: The verify step currently accepts any email from
EmailVerify via onVerified and only sets verifiedEmail without confirming it
belongs to the logged-in account; update the flow so it either (A) performs
ownership validation by comparing the returned email to the current user's email
(e.g., compare verifiedEmail to currentUser.email from props/context inside this
component before enabling the "continue" button or advancing the step) and
reject/mask advancement if they differ, or (B) remove the email verification
step entirely from the password-change flow; additionally consider changing
EmailVerify/onVerified semantics to return an explicit verified flag (not an
arbitrary email) so this component can enforce ownership using verified === true
&& returnedEmail === currentUser.email before calling setVerifiedEmail or
progressing the step.

---

Duplicate comments:
In `@frontend/src/components/mypage/ActivitySection.jsx`:
- Around line 11-27: Add explicit loading and error state handling around the
fetchActivityLogs flow: introduce React state variables (e.g., loading and error
via useState), set loading = true before calling getActivityLogs(page, size) and
set loading = false in finally; on success clear error and call setItems and
setTotalPages as now; on catch set error to the caught error (and optionally
clear items). Update the ActivitySection render logic to branch on loading (show
spinner), error (show error message/retry), non-empty items (render list), and
empty items (render empty state). Apply the same pattern to the other similar
fetch block referenced (lines with the second fetch call).

In `@frontend/src/components/mypage/EditProfileModal.jsx`:
- Around line 130-138: The modal's aria-labelledby points to
"edit-profile-modal-title" but the <h1> rendered by getHeaderTitle() has no
matching id, so add id="edit-profile-modal-title" to the heading element (the
<h1> that displays getHeaderTitle()) in EditProfileModal.jsx so the dialog's
accessible name is announced correctly by screen readers; alternatively, update
the dialog's aria-labelledby to match an existing element id if you prefer a
different target.

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@frontend/src/components/mypage/MyPageMenu.jsx`:
- Around line 63-68: The modal is crashing because ActivityModal expects a data
prop but MyPageMenu wasn’t passing it; update the MyPageMenu ActivityModal
invocation to include data={selectedItem?.data} (or the correct payload on
selectedItem) and in ActivityModal (component) guard any access to data.items
(e.g., only read data.items when kind === 'attendance' && data) while not
passing items to ActivitySection or PointsSection (since they fetch their own
data); reference components: MyPageMenu, ActivityModal, AttendanceSection,
ActivitySection, PointsSection, and prop selectedItem to locate the changes.

---

Duplicate comments:
In `@frontend/src/utils/axios.js`:
- Around line 2-6: The axios instance `api` is created with baseURL set to an
empty string while `BASE_URL` is computed, causing host mismatches (token
refresh at line ~20 uses BASE_URL but other requests do not); update the
`axios.create` call to use the `BASE_URL` constant (i.e., set baseURL: BASE_URL)
and ensure any token refresh/request helpers (the token reissue call referenced
around line 20) also use the same `api` instance or `BASE_URL` so all requests
target the same host.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@frontend/src/components/mypage/ActivityModal.jsx`:
- Around line 21-40: Add focus trapping to the ActivityModal component: store
the previously focused element in a ref when the modal mounts, move focus into
the modal (e.g., to the first focusable child inside the element referenced by
modalContentRef) in useEffect, and restore focus to the saved element when
onClose is called or the component unmounts; add a keydown handler on the modal
(mounted on the element referenced by modalContentRef or modalOverlay) that
intercepts Tab and Shift+Tab to cycle focus among focusable elements inside the
modal so focus cannot escape, and ensure the close button (closeButton) still
triggers onClose and focus restoration.